Site hosted by Angelfire.com: Build your free website today!
Tips 'n Tricks

While programming and studying others' DarkBASIC creations, I noticed some interresting facts. Some are DB specific, other are general DX properties. Be aware that I only have one computer and one card, so maybe it can be different on your computer, but I don't think so.

Mip mapping
MIP (Multum In Parvo) mapping is a texture rendering method that allow multiple resolutions for a single texture. A distant or smal polygon will use a lower resolution texture. This method uses more memory but accelerates the render process while improving the look. Take a note that DB does not allow object transparency and mipmap at the same time. If you want to enable mipmap on a onject, you need to set the mipmap mode to 1(point) or 2(linear), and set the object texture [ object number,tiling mode,1 ] setting the mipmap generation flag to 0 on an object texture will disable the mipmap on this object.

Semi-transparency and ghost mode
DarkBASIC gives you the ghost mode and inverted ghost mode. Be careful with them because they tend to be greedy with the render time. The inverted ghost mode can be very useful to simulate shadows, even lightmapping, while standard ghost mode allows you to made some gorgeous lens flares.
DarkBASIC does not allow you to use ALPHA transparency. The alpha-transparency is the use of an non-addidive / non-substractive transparency, so you could have a gradient from opaque to completely transparent.
There is a way with DB to achieve that effect. But you need to use 2 instances ot your single object, and two separated textures. On the first texture you will have your alpha map (white being opaque) and on the second texture you will have the color map, blended with the inverted alpha map. You will need to have the first object in ghost mode, and the second one in inverted ghost mode. This technique is aslo well suited for GUI/HUD/MENU where sometimes transparency is requred. You can also use this techique to achieve anti-aliasing on 3D sprites.

Time-based game flow
When you set don't block the frame-rate [ sync rate 0 ] your game will be faster on faster computer and slower on slower computer. The problem is that you might not be able to play in two years, your game running too fast. If you are making a racing game, then you won't be albe to compare your time. The cheap way to fix this problem is by blocking the frame-rate to a maximum [ sync rate 40 ]. But you will loose the oportunity to run smoother on tomorrow's computers.
The solution I propose you is to make the game speed dynamicly auto-ajusted. While it sounds wonderfully high-tech, is it still fairly easy to implement.
You firstly need to get time the last frame took to calculate/render. Take the clock time [ timer() ] at each frame, store it in a global variable (array), substract the last stored time from it, and put the result in another global variable. After, all you'll need to do is to multiply each addition by this amount. Be aware that the time given is in millisecond, and you should set the maximum rate to infinite (0)
As an exemple:
FT(1) = Timer() :`get initial time
Do
...T=Timer()
...FT(2)=T-FT(1)
...FT(1)=T
...`old one : inc X#,10
...`old one : Y#=Y#*,10
...inc X#,0.2*FT(2)
...Y#=Y#*10^(FT(2)*0.02)
...print X#,",",Y#
...sync
Loop

Visibility, accelerating by hiding objects
I was implementing a dynamic LOD (Level Of Detail) when I realized this : setting visibility takes time. It's more than just assigning a new value to a variable. I think DB changes othe bject from one list to another or something. So if you repeatedly access visibility, retrieve the object's visibility state before and change it only when needed.
If object visible(obj) then hide object obj
If you are thinking about accelerating the render process by hiding objects out of the screen, be aware that DB already do it with a rough and fast method. I noticed this phenomenon by placing an object at the same place than the camera. Even if the object was big enough to be visible, it was hiden by DB's optimization process.

Implementing dynamic level of detail (LOD)
What does that mean and what does it do ? LOD is just the property of having multiple resolution for a single object. Is is like the MIP system but for objects instead of textures. A static LOD would be to set the details level in a menu and then run the game with this amount of detail. Dynamic LOD is more complex, but nicer. Depending on some variables (mainly the distance, but it could be things like the number of visible objects in the screen, or the frame rate), the system will choose the one model to display among sereval.
Dynamic LOD can't be used with static senery since we are constantly changing visibility state of objects.
How to do it ? The method I use is quite straigth forward. I manually make 3 versions object my object (could be more, as a reference, Serious Sam uses 6 models while Q3A uses 3). I load the 3 meshes. -- I prefer use meshes and then create my objects, it is faster -- I make an object with the first mesh, and add limbs with the 2 others. This way we will have the limbs 0,1,2 (not 1,2,3)
Now at each frames we grab the data to decide what will be the chosen model, and we hide all limbs but the one we want.

3D optimized distance
The standard distance equation is:
Dist#=SQRT( (X1-X2)^2 + (Y1-Y2)^2 + (Z1-Z2)^2 )
The problem is that suqare root calculation is slow. But the most of the time we use distance for comapraison purpose. So instead of square-rooting the distance, we can merely square the compared number. <>br> If Treshold^2>(X1-X2)^2 + (Y1-Y2)^2 + (Z1-Z2)^2 then do_something()
You can also try with a faster (cubic) method before, and grab the real distance after.
<>br> FastDist#=abs(X1-X2) + abs(Y1-Y2) + abs(Z1-Z2)
The last equation is faster mainly because multiplication is a slow process. The real distance equation has 3 multiplications and one square root. Here we only have 3 absolute. Absolute is very is very fast equation, it is the same thing as a bit mask.

Jump and phisics
Once I saw some codes trying to fake a jump with a COS equation. It surely made a round upward trajectory, but isn't very reliable or versatile. Furthermore COS calculation is slow. The best way to make phisics is often to calcul them like the nature calculs it.
Jump calcul is really simple. All you need is two global variables to store the Y value and the vertical speed value. Each frame the object is accelerating downward. If if collides with the floor, then the speed is set to 0. If the object jumps, then the speed is set to a given amount.
do
Yspd#(i)=Yspd#(i)-gravity#
Y#(i)=Y#(i)+Yspd#(i)
if Ycollide(i) then Yspd#(i)=0
loop

I discovered the majority of these tricks by myself, I can be wrong. If you think there is something wrong here, please contact me so I will correct it. If you have some tricks to add to this list, contact me and I'll gladly add it. :)